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Abstract.  Higher-order  model  composition  can  be  employed  as  a  mech¬ 
anism  for  scalable  model  construction.  By  creating  a  description  that 
manipulates  model  fragments  as  first-class  objects,  designers’  work  of 
model  creation  and  maintenance  can  be  greatly  simplified.  In  this  paper, 
we  present  our  approach  to  higher-order  model  composition  based  on 
model  transformation.  We  define  basic  transformation  rules  to  operate 
on  the  graph  structures  of  actor  models.  The  composition  of  basic  trans¬ 
formation  rules  with  heterogeneous  models  of  computation  form  complex 
transformation  systems,  which  we  use  to  construct  large  models.  We  ar¬ 
gue  that  our  approach  is  more  visual  than  the  traditional  approaches 
using  textual  model  descriptions.  It  also  has  the  advantage  of  allowing 
to  dynamically  modify  models  and  to  execute  them  on  the  fly.  Our  argu¬ 
ments  are  supported  by  a  concrete  example  of  constructing  a  distributed 
model  of  arbitrary  size. 


1  Introduction 

We  take  an  actor-oriented  approach  to  the  design  of  embedded  systems.  A  model 
consists  of  actors  as  the  basic  building  blocks,  which  implement  functions  that 
map  signals  at  their  input  ports  to  signals  at  their  output  ports.  The  wiring  be¬ 
tween  output  ports  and  input  ports  represents  transmission  of  unaltered  signals. 
In  a  hierarchical  design,  models  may  contain  models,  in  which  case  the  contained 
models  themselves  act  as  actors.  The  execution  semantics  is  defined  by  the  di¬ 
rector  of  the  model,  if  it  has  one,  or  otherwise  the  director  of  the  containing 
model.  Each  director  implements  a  model  of  computation  (MoC).  Examples  of 
MoCs  include  DE  (Discrete  Event),  SDF  (Synchronous  Dataflow),  FSM  (Finite 
State  Machine),  and  PN  (Karn  Process  Network).  A  heterogeneous  model  uses 
various  MoCs  at  different  levels  of  its  hierarchy.  This  proves  extremely  flexible 
for  system  design,  because  model  designers  can  freely  choose  a  convenient  MoC 
for  any  part  of  the  model.  [1] 

*  This  work  was  supported  in  part  by  the  Center  for  Hybrid  and  Embedded  Software 
Systems  (CHESS)  at  UC  Berkeley,  which  receives  support  from  the  National  Science 
Foundation  (NSF  awards  #0720882  (CSR-EHS:  PRET)  and  #0720841  (CSR-CPS)), 
the  U.  S.  Army  Research  Office  (ARO  #W911NF-07-2-0019),  the  U.  S.  Air  Force 
Office  of  Scientific  Research  (MURI  #FA9550-06-0312),  the  Air  Force  Research  Lab 
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(a)  Top  level  of  the  MapReduce  model 
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(b)  Internal  design  of  the  Split  actor 
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(d)  Internal  design  of  the  Reduce  actor 


(e)  Internal  design  of  the  WaitStop  actor 


Fig.  1.  MapReduce  model  with  2  Map  machines  and  3  Reduce  machines 


In  recent  practice  we  have  seen  large-scale  models  containing  thousands  or 
even  millions  of  actors.  One  concrete  example  is  the  model  for  distributed  word¬ 
counting  created  using  the  MapReduce  programming  paradigm  as  described  by 
Dean  and  Ghemawat  in  Google.  [2]  The  model  is  designed  to  utilize  hundreds 
of  computers  available  in  a  large  cluster  to  count  the  occurrences  of  each  word 
in  a  huge  number  of  web  documents.  We  have  created  a  simplified  demo  using 
5  worker  machines  in  the  Ptolemy  II  modeling  and  simulation  environment  [3], 
as  shown  in  Fig.  1.  Two  of  the  machines  (modeled  by  actors)  provide  the  Map 
functionality  and  three  provide  Reduce.  The  Split  actor,  located  either  on  a 
central  computer  or  on  any  of  the  worker  machines,  distributes  the  key-document 
pairs  received  at  its  input  port  to  the  Map  machines.  The  Map  machines  map 
words  in  the  input  documents  onto  word-number  pairs.  In  this  case,  the  numbers 
in  those  pairs  are  always  1,  each  denoting  a  single  occurrence  of  a  word.  Those 
pairs  are  then  sent  to  the  Reduce  machines  designated  by  the  hash  code  of  the 
words.  Therefore,  pairs  containing  the  same  word  are  always  delivered  to  the 
same  Reduce  machine.  The  Reduce  machines  then  count  the  pairs  for  each  word 
that  they  receive,  and  send  the  result  to  the  Merge  actor  for  output.  When  all 
input  documents  are  processed,  the  WaitStop  actor  receives  a  true-valued  input, 
and  terminates  the  execution. 

It  is  hard  to  imagine  manually  constructing  one  such  model  for  a  large  number 
of  worker  machines.  The  complexity  of  the  work  grows  sharply  as  the  number 
of  actors  increases.  Even  if  the  model  can  be  constructed  manually,  it  is  still 
extremely  difficult  to  modify  or  maintain  the  design.  We  are  thus  motivated  to 
explore  an  approach  to  automated  model  construction  and  modification. 

In  our  prior  work,  we  have  developed  Ptalon  as  a  declarative  language  for 
higher-order  model  composition.  [4]  Textual  model  descriptions  can  be  written  by 
designers  to  manipulate  model  fragments  as  first-class  objects,  and  to  compose 
them  to  generate  large  models.  As  an  example,  the  same  MapReduce  model  is 
constructed  with  Ptalon.  [5]  It  is  shown  that  the  size  of  the  Ptalon  description 
does  not  grow  with  the  increase  of  worker  machines  used  by  the  model.  This  is 
because  the  number  of  worker  machines  is  defined  as  an  integer  parameter  that 
can  be  set  by  the  user. 

In  our  recent  effort  on  higher-order  model  composition,  we  aim  to  provide 
a  more  straightforward  and  user-friendly  mechanism  for  constructing  models. 
We  view  models  as  attributed  graphs,  and  employ  graph  transformation  tech¬ 
nique.  We  have  implemented  a  tool  that  supports  a  visual  language  for  specifying 
transformations.  The  visual  language  is  very  close  to  the  language  that  model 
designers  use  to  manually  create  models.  This  removes  the  need  for  requiring 
model  designers  to  learn  new  languages. 

We  envision  a  variety  of  applications  for  our  technique.  In  this  paper,  we 
present  an  example  for  automated  model  construction  and  execution.  Other 
applications  include  model  optimization,  refactoring,  structural  parametrization, 
and  workflow  automation. 
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(a)  An  example  of  a  hierarchical  model 


(b)  Attributed  graph  representation 


Fig.  2.  Hierarchical  model  and  its  representation  in  attributed  graph 


This  technique  differs  from  Ptalon  in  the  following  ways. 

1.  Models  are  constructed  with  graph  transformation  rules  that  have  a  visual 
representation,  whereas  in  Ptalon,  textual  descriptions  are  used. 

2.  Transformations  can  be  applied  to  existing  models  as  incremental  modifica¬ 
tions  statically  or  dynamically. 

3.  A  hierarchical  heterogeneous  model  can  be  used  to  control  the  application 
of  multiple  transformations. 

The  following  sections  are  organized  as  follows.  In  Section  2,  we  present 
models  as  graphs  and  define  basic  transformations.  In  Section  3,  we  discuss  using 
a  model  to  control  basic  transformations  to  form  a  complex  transformation.  We 
construct  a  MapReduce  model  with  transformation  as  an  example  in  Section  4. 
We  study  the  related  work  in  Section  5,  and  conclude  our  discussion  in  Section  6. 

2  Model  Transformation  Based  on  Graph  Transformation 

Fig.  2  shows  how  a  hierarchical  model  can  be  represented  with  an  attributed 
graph.  In  Fig.  2(b),  vertices  represent  actors,  ports,  and  relations  in  the  model. 
The  styles  of  the  vertices  denote  their  types  encoded  with  attributes,  as  will  be 
discussed  later.  Actors  are  represented  by  big  circles,  ports  represented  by  small 
hollow  circles,  and  relations  by  filled  dots.  There  are  two  types  of  edges.  Dashed 
lines  represent  containment  relationship,  where  the  end  vertices  are  semantically 
contained  by  the  start  vertices.  Solid  lines  represent  connections  between  ports. 
To  represent  a  bidirectional  connection  between  ports,  we  use  two  reversed  di¬ 
rected  edges. 

This  alternative  representation  of  models  allows  us  to  directly  apply  graph 
transformation  techniques  [6]  to  modify  model  structures. 

2.1  Visual  Representation  of  Transformation  Rules 

We  use  a  visual  syntax  to  specify  transformation.  This  syntax  is  inspired  by 
triple  graph  grammar  [7].  A  transformation  is  defined  by  a  transformation  rule , 
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Fig.  3.  A  transformation  rule  for  connecting  a  Map  and  a  Reduce 


which  is  similar  to  a  rewrite  rule  in  a  context-free  grammar.  It  can  be  used 
to  match  a  subgraph  in  a  given  graph,  and  to  replace  that  subgraph  with  a 
replacement  graph.  We  specify  a  transformation  rule  with  three  components:  a 
pattern ,  a  replacement ,  and  the  correspondence  between  objects  in  those  two. 

Fig.  3  shows  a  transformation  rule  designed  for  our  MapReduce  example, 
which  we  will  further  discussed  in  Section  4.  This  rule  creates  connections  be¬ 
tween  the  output  ports  of  a  Map  actor  and  the  input  ports  of  a  Reduce  actor. 
Repeatedly  applying  the  rule  results  in  having  all  the  Map  actors  and  Reduce 
actors  connected  in  this  way.  In  the  pattern,  two  matchers  aim  to  match  two 
distinct  actors  in  the  given  model.  The  names  of  the  matchers  are  insignificant 
and  need  not  be  the  same  as  those  of  the  matched  actors.  Without  consider¬ 
ing  the  constraint,  the  two  matchers  in  the  pattern  match  any  two  such  actors: 
one  with  output  ports  named  “outputKeys”  and  “outputValues,”  and  the  other 
with  input  ports  “inputKeys”  and  “inputValues.”  The  constraint  requires  that 
the  ports  of  the  two  actors  not  be  connected  before  the  transformation  is  applied. 
This  avoids  creating  excessive  connections  between  the  same  pairs  of  ports. 

In  the  replacement,  the  two  matchers  are  preserved,  meaning  that  the  matched 
actors  should  be  kept  after  transformation.  Two  connections  are  to  be  created 
between  their  ports,  because  those  connections  (along  with  the  hidden  relations 
on  them)  do  not  exist  in  the  pattern.  In  general,  designers  of  transformation 
rules  can  specify  adding  or  deleting  objects  by  editing  the  replacement  as  they 
wish.  Note  that  the  names  of  the  matchers  in  the  replacement  need  not  be  the 
same  as  those  in  the  pattern,  because  the  third  component,  the  correspondence 
table,  establishes  the  relations  between  the  two  graphs.  In  this  case,  the  cor¬ 
respondence  table  states  that  the  “Map”  object  in  the  pattern  corresponds  to 
the  “Map”  object  in  the  replacement,  and  the  “Reduce”  object  in  the  pattern 
corresponds  to  the  “Reduce”  object  in  the  replacement.  For  brevity,  we  do  not 
show  correspondence  relations  between  other  types  of  vertices  such  as  ports  and 
relations. 


2.2  Formal  Definition  of  Graph  Transformation 

Our  graph  transformation  is  defined  as  a  modified  version  of  the  double-pushout 
approach  introduced  in  [8]  and  reviewed  in  [9] .  For  completeness,  we  first  review 
that  approach  here. 

A  graph  G  is  a  tuple  ( Vg,Eg ),  where  Vq  is  the  set  of  vertices  in  G  and 
Eg  C  Vq  x  VG  is  the  set  of  edges.  Graph  G  is  a  subgraph  of  graph  H  if  Vq  Q  Vh 
and  Eq  C  Eh- 

A  graph  morphism,  or  simply  morphism,  from  graph  G  to  H  is  a  total  func¬ 
tion  m  :  Vq  —*  Vh,  such  that  for  any  V\ ,  v2  €  Vq,  if  (i>i ,  v2)  £  Eg,  then 
m(y2))  £  Eh-  We  denote  this  morphism  with  G  jj  por  any  vertex 
v  £  Vq,  we  say  v  matches  v'  in  m  if  m(v)  =  v' .  For  any  edge  (vi,i>2)  £  Eq, 
we  say  (vi,v2)  matches  in  m  if  m(v i)  =  v[  and  m(v 2)  =  v'2.  If  m  is  an 

injective  function,  then  we  say  G  is  isomorphic  to  a  subgraph  of  H,  or  G  matches 
a  subgraph  of  H. 

The  composition  of  G  —>  H  with  H  — I  is  G  VEf  where  norn  :  Vq  — >  Vj 
is  the  composition  of  function  m  :  Vq  — >  Vh  and  n  :  Vh  — >  Vj. 
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Fig.  4.  Pushout  of  graph  morphisms 


Given  graphs  G,  H ,  I,  and  morphisms  G  H  and  G  I  as  depicted 
in  Fig.  4,  a  pushout  is  a  tuple  (J,  I  J,H  J),  in  which  J  is  a  graph  and 
morphisms  I  J  and  H  VE,  J  satisfy  the  following  conditions: 

1.  n'  o  m  =  m!  o  n ,  and 

2.  For  any  graph  I\  with  morphisms  H  K  and  I  K  satisfying  x  o  m  = 
yon,  there  exists  a  unique  J  — ^  K  satisfying  z  o  n1  =  x  and  2  o  m!  =  y. 

A  transformation  rule  T ,  denoted  by  ( P  I\  R),  consists  of  graphs 

P ,  K  and  R,  and  injective  morphisms  K  -—>■  P  and  K  R.  P  is  called  the 
pattern  graph  (or  left-hand  side).  R  is  the  replacement  graph  (or  right-hand  side). 
I\  is  the  correspondence  graph  (or  glue  graph)  that  relates  the  vertices  and  edges 
in  the  pattern  and  those  in  the  replacement. 
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Fig.  5.  Graph  transformation  based  on  double-pushout 


Given  transformation  rule  T  =  (P  I\  — R)  and  input  graph  /,  if  an 
injective  morphism  P  — /  exists  (i.e.,  P  matches  a  subgraph  of  I),  then  T 
is  applicable  to  I.  If  applicable,  the  result  of  applying  T  to  /,  as  depicted  in 
Fig.  5,  is  an  output  graph  O,  such  that  there  exist  graph  D ,  injective  morphisms 

K  — D  and  R  — r—>  O,  and  morphisms  D  ■—>  I  and  D  O,  such  that 
(/,  P  — ^  /,  D  —>  I)  and  (O,  R  — r—>  O ,  D  O)  are  both  pushouts. 

2.3  Attributes 

In  order  to  transform  models  using  graph  transformation,  it  is  necessary  to  cat¬ 
egorize  vertices  and  edges  of  different  types.  (Recall  that  three  types  of  vertices 
and  two  types  of  edges  are  used  in  Fig.  2.)  It  is  also  necessary  to  take  into  account 
other  attributes  that  further  differentiate  vertices,  such  as  the  ones  that  decide 
whether  a  port  is  input  port  or  output  port.  Therefore,  we  let  A  be  a  globally 
defined  attribute  set,  and  extend  the  definition  of  graph  G  to  be  (Vg,Eg,Ag), 
where  Aq  :  (Vq  U  Eg)  — >  2A  is  a  total  function  that  returns  a  (possibly  empty) 
set  of  attributes  for  each  vertex  and  edge. 

Our  other  definitions  in  the  previous  subsection  remain  unchanged,  except 
that  the  definition  of  graph  morphism  is  enhanced  next  to  take  into  consideration 
the  attributes. 

2.4  Criteria  Attributes  and  Operation  Attributes 

We  define  a  subset  of  attributes  U  C  A  to  be  unchecked  attributes.  It  contains 
attributes  that  need  not  be  directly  checked  in  the  extended  graph  morphisms  to 
be  defined  below.  A  subset  of  unchecked  attributes,  C  C  U,  is  called  criteria.  Let 
B  be  an  auxiliary  set  that  equals  2A  x2A.  We  require  any  criterion  c  £  C  to  be 
an  element  in  2s.  Given  two  vertices  or  edges  x  €  ( Vq^Eg )  and  y  €  ( VrGEh ), 
we  say  that  criterion  c  is  satisfied  by  x  matching  y  if  (Ag(x),  Ah(v))  G  c. 

We  now  extend  the  definition  of  graph  morphism  discussed  in  Sec.  2.2  to 
become  the  following.  An  attributed  graph  morphism  from  graph  G  to  H  is  a 
graph  morphism  m  :  Vq  — >  Vr  satisfying  the  following  additional  conditions: 

1.  for  any  v  G  Vq, 

(a)  Va  e  (Aq(u)  \  U).  a  <£  AH(m(v)) 


(b)  Vc  G  (AG(u)  H  c).  (AG(v),AH(m(v)))  Gc 
2.  for  any  {vi,v2)  G  EG, 

(a)  Va  G  (Ag((v i,u2))  \  U).  a€  AH  ((m(vi),m(v2))) 

(b)  Vc  G  (-4g((ui,u2))  n  G).  (4G((«i,ti2)),4fl((m(vi),m(ti2))))  Gc 

Case  (a)  of  the  two  conditions  requires  that  all  attributes  belonging  to  a 
vertex  or  edge  in  G,  except  the  unchecked  ones,  be  associated  with  the  matched 
vertex  or  edge  in  H .  Therefore,  the  unchecked  attributes  of  the  latter  form  a 
superset  of  those  of  the  former.  Case  (b)  of  the  two  conditions  ensures  that  the 
criteria  associated  any  vertex  or  edge  in  G  be  satisfied  by  the  matching. 

Practically,  for  a  transformation  depicted  in  Fig.  5,  only  the  graphs  P  and 
R  contain  vertices  and  edges  with  criteria  attributes.  In  particular,  we  call  the 
criteria  in  the  replacement  graph  R  operations,  since  they  essentially  enforce 
restrictions  on  the  output  graph  that  may  be  satisfied  by  performing  additional 
attribute  adding  or  removal  operations.  (In  this  discussion,  we  assume  that  those 
criteria  in  R  can  be  satisfied  by  adding  or  removing  attributes  in  the  output 
graph  O.) 

Because  of  the  criteria  in  P  and  R,  it  may  not  be  possible  to  apply  trans¬ 
formation  rule  T  to  input  graph  I  even  if  it  is  applicable  in  the  sense  that  the 
pattern  P  matches  a  subgraph  of  I.  Thus,  we  define  total  function  Ft  :  G  — ■>  G 
to  return  the  result  of  applying  T,  where  G  is  the  set  of  all  graphs.  If  T  is  appli¬ 
cable  to  the  given  input  graph  and  an  output  graph  can  be  obtained,  then  Ft 
returns  that  output  graph;  otherwise,  Ft  simply  returns  the  input  graph. 

2.5  Model  Transformation 

The  example  in  Fig.  2  shows  a  way  to  represent  a  model  with  an  attributed  graph. 
In  the  attributed  graph,  three  special  attributes  are  assigned  to  the  vertices  to 
distinguish  their  types:  Actor  (visually  represented  by  big  circles),  Port  (small 
hollow  circles)  and  Relation  (filled  dots).  Two  additional  attributes  identify  the 
types  of  the  edges:  Containment  (dashed  lines)  and  Connection  (solid  lines) .  The 
names  of  the  vertices  are  unchecked  attributes  that  are  unique  at  each  level  of 
the  hierarchy  of  a  transformation  rule.  Names  at  different  levels  may  be  identical. 


Fig.  6.  The  model  transformation  process 


Using  the  graph  representation,  we  establish  a  model  transformation  process 
as  shown  in  Fig.  6.  The  inputs  to  the  process  consist  of  an  input  model  and  a 


transformation  rule,  both  specified  in  the  modeling  language.  (Fig.  1  and  Fig.  3 
provide  examples  of  both  in  this  language.)  The  two  inputs  are  then  converted 
into  attributed  graphs.  To  convert  a  model  into  an  attributed  graph,  a  vertex  is 
created  for  each  actor,  port  or  relation,  and  an  edge  is  created  for  each  connection 
or  containment  relation.  (We  use  two  reversed  edges  with  the  same  attributes  to 
simulate  an  undirected  edge  in  Fig.  2.) 

The  transformation  rule  is  converted  into  multiple  graphs.  Its  pattern  and 
replacement  contain  model  fragments  and  are  converted  into  the  P  graph  and  the 
R  graph  in  Figure  5.  The  correspondence  table  simplifies  the  specification  of  the 
K  graph.  Its  “Pattern”  column  shows  the  names  of  the  actors  in  the  pattern.  (For 
clearer  presentation,  we  hide  the  vertices  corresponding  to  ports  and  relations  as 
well  as  all  edges.)  For  a  hierarchical  transformation  rule,  the  names  may  contain 
parts  separated  by  dots,  referring  to  the  unique  identifiers  at  different  levels. 
The  “Replacement”  column  shows  the  names  of  the  corresponding  actors  in  the 
replacement.  There  is  a  one-to-one  relationship  between  entries  in  both  columns. 
Conceptually  the  conversion  process  computes  a  subgraph  of  P  as  K ,  such  that 
K  contains  only  vertices  listed  in  the  “Pattern”  column.  The  one-to-one  nature 
ensures  that  a  subgraph  exists  in  R  that  is  isomorphic  to  this  selection  of  K . 

After  the  conversion,  graph  transformation  can  be  applied.  The  transforma¬ 
tion  result  is  converted  back  into  a  model  for  output. 


3  Model-Based  Transformation 

In  Section  2.4  we  discussed  considering  transformation  rule  T  to  be  a  function 
Ft  :  G  — >  G  that  takes  a  graph  (or  model)  as  input  and  produces  an  output.  This 
allows  us  to  encapsulate  the  transformation  rule  in  a  TransformationRule  actor 
whose  functionality  is  defined  by  Ft-  This  actor  can  be  embedded  in  models  using 
arbitrary  models  of  computation  (MoCs).  We  call  our  approach  of  employing 
hierarchical  heterogeneous  models  to  control  transformation  rules  model-based 
transformation.  We  call  the  transformation  in  a  single  TransformationRule  actor 
a  basic  transformation,  as  opposed  to  the  transformation  obtained  by  composing 
TransformationRule  actors  in  a  model. 


3.1  TransformationRule  Actor 

A  TransformationRule  actor  has  a  single  input  port  and  two  output  ports.  The 
input  port  accepts  actor  tokens  that  contain  models  to  be  transformed.  An  out¬ 
put  port  (the  one  appearing  to  the  right  in  its  visual  representation)  outputs 
the  results  by  applying  Ft  to  the  inputs.  Another  output  port  (visually  shown 
at  the  bottom  of  the  actor’s  icon)  produces  true  or  false  to  signify  whether  the 
pattern  of  the  transformation  rule  matches  any  subgraph  of  the  input  model. 

When  the  TransformationRule  actor  is  opened  in  the  Ptolemy  II  GUI  (Graph¬ 
ical  User  Interface),  an  interface  appears  to  allow  the  designer  to  edit  the  trans¬ 
formation  rule  that  this  actor  represents.  This  interface  has  a  tab  for  each  of  the 
three  components,  as  is  shown  in  Figure  3.  Among  these,  the  correspondence 


table  is  automatically  maintained  most  of  the  time.  When  an  actor  is  copied 
from  the  “Pattern”  tab  and  pasted  to  the  “Replacement”  tab,  a  row  is  automat¬ 
ically  created  to  establish  the  correspondence  relation.  Deleting  an  actor  may 
also  cause  removal  of  a  row. 


3.2  A  Library  of  Actors  for  Model-Based  Transformation 

In  addition  to  TransformationRule,  we  have  created  other  actors  in  an  actor 
library  for  model-based  transformation. 

ModelGenerator  is  used  to  generate  initial  actor  tokens.  It  has  different  us¬ 
ages.  If  an  input  string  containing  the  description  of  a  model  in  the  Modeling 
Markup  Language  (MoML)  is  provided,  it  parses  the  string  and  sends  the  model 
via  its  output  port.  If  only  a  model  name  is  provided,  it  creates  an  empty  model 
with  the  given  name. 

ModelCombine  accepts  multiple  input  models  at  each  time.  It  merges  those 
models  and  outputs  a  combined  model.  Suppose  the  n  input  models  are  repre¬ 
sented  with  graphs  G\,G2,  ■  ■  ■  ,Gn,  then  the  output  model  can  be  represented 
with  G  =  (Vg,  Eg,  Ag),  where  Vq,  Eg  and  Aq  are  the  disjoint  unions  of  the  ver¬ 
tex  sets,  edge  sets  and  attribute  functions  (considered  as  sets  of  argument- value 
pairs)  of  the  input  graphs.  We  take  an  extra  step  after  the  merging  to  update 
the  name  attributes  so  that  they  are  unique  at  each  level  of  the  resulting  model. 

ModelView  displays  the  input  models  in  a  separate  window.  It  updates  the 
window  when  a  new  actor  token  is  received.  After  displaying  the  model  in  the 
actor  token,  it  sends  the  token  to  downstream  actors  via  its  output  port. 

ModelExecutor  executes  the  input  models  to  completion.  Inputs  can  be  pro¬ 
vided  to  the  models  being  executed  via  user-customized  input  ports  of  Mod¬ 
elExecutor.  The  tokens  available  at  those  input  ports  are  automatically  trans¬ 
mitted  to  the  input  ports  with  the  same  names  of  the  executed  models  that 
have  the  same  names.  Outputs  from  the  models  are  also  transmitted  to  the 
user-customized  output  ports. 

MoMLGenerator  exports  the  input  models  in  the  Modeling  Markup  Lan¬ 
guage  (MoML).  The  exported  strings  can  be  written  into  files  by  File  Writer. 


3.3  Applications 

There  is  a  large  variety  of  applications  for  model-based  transformation.  We 
sketch  some  of  them  here.  A  concrete  example  of  the  model  construction  ap¬ 
plication  will  be  discussed  in  the  next  section. 

—  Model  construction.  ModelGenerator  can  be  used  to  generate  empty  mod¬ 
els,  which  are  first-class  objects  manipulated  by  a  higher-order  model  (the 
one  that  contains  the  ModelGenerator).  Arbitrary  models  can  thus  be  con¬ 
structed  by  modifying  empty  models  with  transformations.  The  constructed 
models  can  be  executed  by  ModelExecutor  on  the  fly,  or  be  stored  in  files 
by  MoMLGenerator  and  File  Writer. 


—  Model  optimization.  When  appropriate  information  about  model  behavior 
is  provided,  model  transformation  can  be  used  to  optimize  existing  models 
while  preserving  their  behavior.  One  example  is  to  partially  evaluate  a  given 
model  by  eliminating  the  parts  of  computation  logic  that  output  signals  that 
can  be  computed  statically.  The  validity  is  based  on  the  information  about 
whether  the  actors’  outputs  are  constant,  or  how  actors’  outputs  depend  on 
their  inputs.  This  information  may  be  provided  in  the  actors’  behavioral  in¬ 
terface  [10],  or  be  obtained  with  a  static  analysis  of  the  code  that  implements 
the  actors. 

—  Design  refactoring.  Refactoring  also  preserves  model  behavior.  It  usually 
aims  to  improve  model  designs  for  better  understandability  or  easier  main¬ 
tenance.  Take  hierarchy  flattening  as  an  example.  For  some  models,  hierarchy 
may  be  eliminated  by  moving  actors  to  higher  levels.  An  opposite  operation 
is  to  introduce  extra  levels  to  the  hierarchy  by  encapsulating  actors,  which 
helps  clarify  the  design  and  protect  the  encapsulated  parts. 

—  Structural  parametrization.  Models  can  be  parametrized  with  placeholders 
defined  in  their  structures.  Model  transformations  can  be  used  to  config¬ 
ure  those  placeholders  to  form  complete  models.  Compared  to  value-based 
parametrization,  structural  parametrization  is  a  generalization  that  pro¬ 
vides  more  design  flexibility  and  reuse  opportunity.  Furthermore,  one  can 
construct  a  class  hierarchy  for  models,  where  models  at  each  level  (except 
the  root  level)  are  variants  obtained  from  structurally  parametrizing  some 
models  at  a  higher  level.  Formal  checking,  using  for  example  interface  au¬ 
tomata  [11],  can  be  incorporated  to  guarantee  behavioral  properties.  This 
leads  to  an  actor-oriented  subclassing  mechanism  that  generalizes  the  work 
in  [12]. 

—  Execution  parallelization.  Using  a  model  of  computation  that  provides  con¬ 
currency,  multiple  models  can  be  executed  in  parallel  with  ModelExecutors. 
Those  models  can  communicate  with  each  other  via  the  user-customized  in¬ 
put  ports  and  output  ports  of  the  ModelExecutors.  This  makes  it  possible 
to  simulate  a  distributed  system,  where  the  models  are  executed  on  separate 
computers  and  communicate  with  each  other. 

—  Workflow  automation.  Model-based  transformation  can  also  be  used  to  auto¬ 
mate  tasks  in  the  model  development  workflow.  Those  tasks  include  compo¬ 
nent  configuration  and  composition,  version  control,  and  regression  testing. 


4  MapReduce  Example 

In  this  section  we  discuss  a  parametrized  higher-order  model  that  generates  a 
MapReduce  model  and  executes  it.  Fig.  7  shows  part  of  the  hierarchy  of  this 
higher-order  model.  A  parameter  at  the  top  level,  numberOfMachines,  defines 
the  preferred  number  of  worker  machines,  which  can  be  set  by  the  user.  For 
simulation,  we  use  a  FileReader  to  read  the  documents  from  disk  and  to  output 
them  in  tokens  via  the  upper  output  port.  The  lower  output  port  produces  true 
when  all  documents  are  sent,  or  false  otherwise.  When  it  outputs  false,  the  doc¬ 
ument  tokens  are  queued  in  the  buffer  for  the  ModelExecutor’s  upper-left  input 
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Fig.  7.  A  higher-order  model  that  generates  a  MapReduce  model  and  executes  it 


port.  When  it  outputs  true,  the  Switch  sends  a  token  to  the  CreateMapReduce 
actor,  triggering  it  to  generate  a  MapReduce  model  in  an  actor  token.  (Fig.  1 
shows  the  MapReduce  model  generated  when  numberOfMachines  equals  5.)  The 
model  is  then  sent  to  the  ModelExecutor  for  immediate  execution.  The  buffered 
documents  are  provided  to  the  model  as  inputs  at  its  “document”  input  port, 
and  its  outputs  to  the  “result”  output  port  are  automatically  transmitted  to  the 
Display  actor  connected  to  the  ModelExecutor’s  output  port. 

The  CreateMapReduce  actor  contains  an  SDF  (Synchronous  Dataflow)  model 
that  controls  several  TransformationR.ule  actors  (each  represented  with  a  yolk¬ 
like  icon  surrounded  by  a  box).  mapCount  is  defined  to  be  the  number  of  Map 
machines,  and  reduceCount  is  the  number  of  Reduce  machines.  Fig.  8  shows 
the  transformation  rules  in  the  CreateSplit  actor.  It  creates  a  Split  actor  and  a 
Merge  actor,  together  with  the  input  ports  and  output  port  of  the  MapReduce 
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Fig.  8.  The  transformation  rule  in  CreateSplit 


model.  Its  pattern  is  deliberately  made  empty  so  that  the  transformation  rule  is 
applicable  to  the  empty  model  generated  by  the  ModelGenerator.  In  Fig.  3,  we 
have  shown  the  transformation  rule  in  the  LinkMapAndReduce  actor.  It  con¬ 
nects  the  ports  of  an  arbitrary  Map  actor  and  an  arbitrary  Reduce  actor,  with 
a  constraint  to  make  sure  that  no  duplicated  connections  are  made  in  multi¬ 
ple  applications  of  the  same  transformation  rule.  We  set  a  special  parameter, 
which  is  not  shown  in  the  interface,  so  that  the  transformation  is  applied  ex¬ 
actly  (mapCount  x  reduceCount)  times  for  each  input  model,  so  that  all  the  Map 
actors  and  Reduce  actors  in  it  are  interconnected. 

This  example  shows  how  we  use  model  transformation  as  a  tool  to  construct 
a  complex  model.  The  size  of  the  dynamically  generated  model  is  parametrizable 
with  an  integer  parameter,  and  has  no  impact  on  the  size  of  the  higher-order 
model  that  the  designer  manually  creates.  Each  TransformationRule  actor  can 
be  separately  designed,  documented  and  maintained.  It  can  also  be  parametrized 
and  reused  to  construct  other  models. 

5  Related  Work 

Model  transformation  has  been  under  active  research  in  recent  years.  In  recog¬ 
nition  of  the  public  interest,  the  OMG  (Object  Management  Group)  has  issued 
a  request  for  proposal  (RFP)  on  MOF  (Meta-Object  Facility)  QVT  (Query  / 
Views  /  Transformations)  to  seek  a  standardized  approach  to  model  transfor¬ 
mation  [13]. 

Besides  our  model  transformation  tool  developed  in  the  Ptolemy  II  frame¬ 
work,  existing  tools  include  AGG  [14],  PROGRES  [15],  AToM3  [16],  FUJABA  [17], 
VIATRA2  [18],  and  GReAT  [19].  Among  those,  our  tool  is  the  only  one  that 
supports  a  large  and  extensible  collection  of  MoCs  for  controlling  basic  trans- 


formations.  By  carefully  choosing  MoCs,  sequential  transformation  and  parallel 
transformation  can  be  achieved,  as  well  as  a  mixture  of  both.  This  control  mech¬ 
anism  is  more  flexible  than  the  priority-based  control  provided  by  AGG  and 
AToM3,  the  imperative  program  control  implemented  in  PROGRES,  and  the 
restricted  selection  of  MoCs  that  the  other  tools  offer.  Furthermore,  our  model 
transformation  tool  provides  a  user-friendly  language  for  transformation  specifi¬ 
cation.  It  employs  the  same  visual  language  as  that  used  for  manually  creating 
models.  This  frees  designers  from  learning  another  language  for  specifying  trans¬ 
formations  (such  as  a  textual  language  and  UML  class  diagrams),  understanding 
the  meta-models  of  their  models,  and  describing  their  transformations  in  terms  of 
the  meta- models.  Higher-order  model  composition  for  embedded  system  design 
is  proposed  in  [20]  and  [21].  Compared  to  other  related  approaches  in  this  field, 
such  as  Ptalon  [4]  and  higher-order  Petri  nets  [22],  our  model-based  transforma¬ 
tion  approach  allows  designers  to  visually  describe  pieces  of  model  structures  and 
to  transform  them  step  by  step.  Besides,  our  model  descriptions  are  themselves 
hierarchical  heterogeneous  models,  which  can  be  divided  into  parametrized  com¬ 
ponents  for  reuse.  Therefore,  not  only  the  models  constructed  by  the  descriptions 
can  easily  scale  to  large  sizes,  the  descriptions  themselves  are  also  scalable. 


6  Conclusion 

We  present  our  approach  to  higher-order  model  composition  based  on  model 
transformation.  We  provide  a  formal  definition  of  graph  transformation,  which 
serves  as  the  basis  of  our  model  transformation  technique.  We  show  that  basic 
transformations  can  be  used  as  actors  in  a  hierarchical  heterogeneous  models. 
Our  approach  makes  it  easy  to  create  complex  transformations  as  composition 
of  basic  ones.  We  provide  a  word-counting  model  designed  using  the  MapReduce 
programming  pattern  as  a  concrete  example. 
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